Tests verified by hand against Q8V336 (NCAP_DUGBA) in the test proteome.

QNALVEATRFC is constructed so the only match in the test proteome requires
deleting Q at query position 0 (terminal). Verified that removing the guard
produces a spurious NALVEATRFC hit; the guard correctly blocks it.
Also adds *.pepidx to .gitignore to prevent index files from being staged.

Deletions at query position 0 or query_len-1 are now permitted when the
protein position is not at a sequence boundary, allowing valid biological
indel matches that were previously blocked.

Previously the indel count rode in the Mismatches slot. Split it into
its own column (right after Mismatches in FINAL_COLUMNS) so indel rows
report Mismatches=0/Indels=N and non-indel rows report Indels=0,
without disturbing existing Mismatches semantics for exact/mismatch/
discontinuous search. Per PR IEDB#24 review item 3.

is_terminal_deletion treated p_idx == 0 and p_idx == protein_len - 1 as
boundary artifacts, but both are real, existing residues, not
out-of-bounds. This required 2 residues of protein context around a
deletion's gap when 1 is sufficient (a real adjacent residue already
confirms the query residue is genuinely absent, not just missing
because the recorded sequence happens to end there). Only strictly
out-of-bounds references (p_idx < 0 or p_idx >= protein_len) are
actually ambiguous.

- Replace indel.py's seed/DFS port with a genuinely independent
  brute-force oracle (direct window enumeration, no seeding/recursion)
  so it can catch bugs the DFS and its Python port would share
- Add ValueError path tests for max_indels>1 and indel+mismatch combos
- Add peptide_len < k edge case test
- Add multi-hit test covering two different proteins in one query
- Add randomized property test comparing Rust output against the
  brute-force oracle across 25 seeded random peptide/proteome pairs

Silently kicking off a full-proteome preprocessing pass with a terse
message is a surprise for large proteomes. Per PR IEDB#24 review item 5.

Per PR IEDB#24 review item 6.

Trailing constraint note (after the code block) rather than folded
into the intro sentence, mirroring how Counts-Only Mode documents its
best_match incompatibility.

…ts_only

Both combinations previously produced silent wrong behavior: best_match
was ignored (indel_search() results were never passed through
_best_match_filter), and counts_only silently returned exact-match
counts (max_mismatches=0) rather than indel counts. Neither is
implemented yet, so both now fail loudly like the existing
max_indels/max_mismatches mutual-exclusivity check.

_with_deletion/_with_insertion are named for the edit applied to the
query string, which is the opposite of the Indels label the search
engine reports for the resulting match (removing a query residue
means the protein has extra content there, an insertion match, and
vice versa). Noted during audit to prevent misreading.

A deletion at the query's own first or last residue has no query-side
context to confirm the residue is genuinely absent, as opposed to the
alignment simply starting/ending one residue short -- so it's now
blocked regardless of protein-side buffer, reverting the earlier
relaxation. Applied identically to match.rs's is_terminal_deletion and
the brute-force oracle, so both stay in lockstep.

Added test_terminal_insertion_blocked and
test_insertion_at_second_to_last_position_found to cover the analogous
insertion case: a padded leading/trailing insertion is unverifiable
and blocked, while an interior insertion one position before the
query's own boundary (e.g. LPDGVWEESS) has real query-side context on
both sides and remains valid.

Renamed indel.py to indel_brute_force.py for clarity ahead of future
2-indel brute-force work.